First of all. The following monitoring uses an older version , Zabbix 2.2.
On top of that, please tell me if there are similar problems in recent versions.
Since it is not a problem specific to the monitoring target, I do not disclose the model name of the target device, but I use SNMPv3 for monitoring.
As long as I confirmed the packet dump, the agent of the target device seems to be implemented using NetSNMP.
The problem is the timing to acquire information related to engineID that Zabbix 2.2 should perform when polling with SNMPv3.
Information related to engineID includes engineID, engineboots, and enginetime.
Many SNMP agent implementations (many target devices) restart the agent when SNMPv3 settings are changed, so the engineboots and enginetime values are updated.
In Zabbix 2.2, I think that information related to engineID is only acquired at the following timing.
1. When an item is first registered
2. When Zabbix 2.2 server restarts
Because of this problem, it is necessary to restart the Zabbix 2.2 server whenever the SNMP settings of the target device are changed or restarted.
The reason is that the target device does not respond to polling with significantly different enginetime.
Specifically, the implementation of the target device does not respond to polling if Zabbix enginetime is greater than the target device enginetime.
The above behavior is not bug for SNMPv3, but rather correct. So I think there is a problem with the Zabbix 2.2 implementation.
If you are using Zabbix to monitor with SNMPv3, please tell me how you are tackling this problem.
As a workaround, I'm glad if there is an SNMPv3 option that always polls engineboots and enginetime with constants.
For example, Net-SNMP command-line tools such as snmpbulkget can do the same by using the "-Z" option.
Of course, I think the protocol called SNMPv3 is extremely vulnerable to replay protection, so it's better to use SNMPv2c over IPsec.
In v2c, User-based Security Model (USM) does not work, but in Net-SNMP, the same thing can be done using community names. I think it's more realistic to use SNMPv2c over IPsec than to SNMPv3 which doesn't work.
Unfortunately, even Internal Revenue Service uses SNMPv3. As far as I heard, IRS doesn't seem to use USM effectively.
Ideally, I think HTTPS should provide a REST interface to the MIB. In that case, the MIB should be handled as an XML database. I want someone to standardize ...
Really, SNMP seems like a curse for me.
On top of that, please tell me if there are similar problems in recent versions.
Since it is not a problem specific to the monitoring target, I do not disclose the model name of the target device, but I use SNMPv3 for monitoring.
As long as I confirmed the packet dump, the agent of the target device seems to be implemented using NetSNMP.
The problem is the timing to acquire information related to engineID that Zabbix 2.2 should perform when polling with SNMPv3.
Information related to engineID includes engineID, engineboots, and enginetime.
Many SNMP agent implementations (many target devices) restart the agent when SNMPv3 settings are changed, so the engineboots and enginetime values are updated.
In Zabbix 2.2, I think that information related to engineID is only acquired at the following timing.
1. When an item is first registered
2. When Zabbix 2.2 server restarts
Because of this problem, it is necessary to restart the Zabbix 2.2 server whenever the SNMP settings of the target device are changed or restarted.
The reason is that the target device does not respond to polling with significantly different enginetime.
Specifically, the implementation of the target device does not respond to polling if Zabbix enginetime is greater than the target device enginetime.
The above behavior is not bug for SNMPv3, but rather correct. So I think there is a problem with the Zabbix 2.2 implementation.
If you are using Zabbix to monitor with SNMPv3, please tell me how you are tackling this problem.
As a workaround, I'm glad if there is an SNMPv3 option that always polls engineboots and enginetime with constants.
For example, Net-SNMP command-line tools such as snmpbulkget can do the same by using the "-Z" option.
Of course, I think the protocol called SNMPv3 is extremely vulnerable to replay protection, so it's better to use SNMPv2c over IPsec.
In v2c, User-based Security Model (USM) does not work, but in Net-SNMP, the same thing can be done using community names. I think it's more realistic to use SNMPv2c over IPsec than to SNMPv3 which doesn't work.
Unfortunately, even Internal Revenue Service uses SNMPv3. As far as I heard, IRS doesn't seem to use USM effectively.
Ideally, I think HTTPS should provide a REST interface to the MIB. In that case, the MIB should be handled as an XML database. I want someone to standardize ...
Really, SNMP seems like a curse for me.